Fixes: #8249

See also ACINQ/eclair#2899 for more background.

Although zero-fee commitments are on the horizon it will be probably take longer until all new channels are upgraded to this new type where we basically don't need those exceptions anymore. With the current channel type we need this exception to make splicing work and also protect against some force closes with other node implementation e.g. eclair which excepts the dipping into the reserve in some case.

There are some cases where we should allow the peer paying the channel fees (channel opener) to be dipped into its reserve. These will be detailed in the following to have an easier way to understand this PR.

We need to look at this problem from the perspective of the different messages which are allowed to change the channel state in Lightning causing the commitment fees to potentially increase. (Update_FullFill and Update_Fail are not mentioned here because they do not increase the fee requirements but only resolve htlcs from the commitment).

1. Receive HTLC
2. Send HTLC
3. Receive CommitSig
4. Send CommitSig (alias SignNextCommitment)
5. Send FeeUpdate (Opener only)
6. Receive FeeUpdate (Non-Opener only)

Now we need to look at those messages from the perspective of the channel opener paying the fees and the non-opener.

In general ONLY the peer paying the fees is allowed to be dipped into its reserve. A non-opener can be below the reserve (when a channel without push_amt is opened) but the balance should only increase not decrease hence its important to notice that we are only looking into the cases where the initial balance of one side decreased.

Channel Opener:
Looking into the case when the local reserve is allowed to be dipped.

1. When receiving an Update HTLC should be allowed to be dipped into its local reserve unconditionally (solves the splicing case, resolves stuck channels, helps in the concurrent case where and outgoing and incoming were added at the same time.
2. Sending an HTLC the local reserve is not allowed to be dipped into its reserve, we also have the feeBuffer in place here so this should never happen.
3. Signing the Next State, here we essentially need to skip the LocalReserve Check because objectively speaking we don't need to check this constraint here because all changes and the constraints are already done in the other cases. However I decided to keep this check but just not fail if we fall below the reserve because of the concurrent adding of HTLCs. The problem at this point is that we cannot really know which side dipped the local here into its reserve therefore we just allow it.
4. Same as 3, we basically skip the local reserve check by allow the local reserve to be dipped at this stage.
5. Sending FeeUpdate we already keep an additional buffer and don't allow the local reserve to be dipped here. We will not attempt the FeeUpdate if we are below the local reserve. This is no problem because the state has not locked in yet.
6. Cannot Receive the FeeUpdate because the Opener creates it.

Channel Non-Opener.
We look now when the remote reserve is allowed to be dipped.

1. When receiving an HTLC, we do not allow the peer to be dipped into its reserve, we always evaluate the htlc against the acked outgoing htlcs, so the peer is never allowed to dip himself into the reserve.
2. Sending an HTLC, we allow the dipping into the remote reserve => ONLY add this via a config flag so we don't mess with older LND nodes ?
3. Skip the remote check here same as for the opener case
4. Skip the remote check here same as for the opener case
5. Not applicable
6. Don't allow the Peer to dip into its reserve via the fee update because we check this new proposal against the already ACKED outgoing htlcs. But because we might have already unsigned Outgoing HTLCs from our point of we, this would allow the peer to dip into its reserve implicitly by the weight of the unsigned outgoing HTLCs. => This case is important to prevent force closes with other nodes like eclair, which already takes the dipping into the reserve into account here.